避免致命的五大单元测试弊端-控件新闻-慧都网

避免致命的五大单元测试弊端

原创|行业资讯|编辑：龚雪|2014-10-20 09:26:15.000|阅读 309 次

概述：单元测试的需求越来越大，开发者或开发者团队的工作压力或技术局限，导致单元测试漏洞频发。

世界著名开发测试公司PRQA与Parasoft或多或少的让开发者知道了单元测试框架的概念。相对于单元测试的需求，开发者暴露出来的测试问题，总结下来可以归结五大漏洞。

1. 跟协作逻辑一起来测试算法。如果跟协作逻辑代码分离开来，那么算法逻辑是最容易测试的。否则在你的逻辑被测试之前，你就不得不先进行诸如通过任务队列提交一个任务之类的工作。任务队列部分只会使事情变得复杂。除非你想测试任务队列本身，否则你就应当把调用run方法时所执行的逻辑剥离开来，并对它进行单独测试。那样，不论是编码还是测试都会更易于编写和管理。

2. Mock测试太多。也许单元测试的最大好处就是它迫使你编写能够独立测试的代码。也就是说，你的代码会变得模块化。当你把你要处理的对象的周围的一切都模拟了，就没有什么能迫使你去把各部分分离开来。你会发现这样写出的代码，你很难在外围添加独立的部分 – 因为所有东西都纠缠在一起。

3. 不使用断言。有时我会看到一些测试，里面创建了一个对象，调用了一些方法，然后，就没有然后了。也许它是在循环里这样做的，而且在创建和调用上会有些差异。但是，却没有用断言来做任何检查。这就完全失去了意义 – 没有检查你的代码是否按照预期进行工作的。当然，代码是运行了，但是仅此而已。如果抛出了一个异常，我们会注意到它，但是却不会验证其它任何事情。

4. 在测试代码中遗留print语句。我把这视为手工测试的后遗症 – 你希望看到对象的值来判断它们是否正确。但是所有的检查都应当使用断言来完成。如果单元失败了，你也能看到它，因为这个测试也会失败。当测试通过时，什么也不应当打印出来。在编写测试代码时，使用print语句有时是有用的。但是在需要用print的地方应当设置一个标志位，用来在进行测试的时候屏蔽它。

5. 查看日志信息，而不是运行结果。还好这并不普遍，但是我却见过一个非常有能力的开发人员这么干过。要知道，真正重要的是方法的运行结果，而不是日志中都打印了什么，因为即使代码中有错误，测试也可能会通过。

从总结的五大弊端来看，有思想上的滞后，有技术上的缺陷，有人为能力的限制等，当然还有很多，这五条是最常见或最难处理的。只能根据开发团队自己内部调整，但也可以使用一定的测试工具（PRQA与Parasoft测试工具性价比非常高）。

标签：软件测试技术

本站文章除注明转载外，均为本站原创或翻译。欢迎任何形式的转载，但请务必注明出处、不得修改原文相关链接，如果存在内容上的异议请邮件反馈至chenjj@evget.com

上一篇：提高代码质量之如何设计函数下一篇：C/C++单元测试框架昂贵的原因